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Abstract 


As BPM takes off within the organization, the challenge becomes one of delivering on 
the promise across a broad front. This paper focuses on how to create an effective 
methodology and organizational capability to meet this challenge. It presents a wide 
variety of best practice tips and pitfalls to avoid, highlighting the experiences of 
several major enterprises pursuing business transformation via BPM. 
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Introduction 


Once the first Business Process Management (BPM) project is completed, 
opportunities begin to emerge from all corners of the organization. Executives and 
Line of Business (LOB) Managers soon appreciate the potential for BPM technology to 
help them radically improve business performance as they drive the organization to 
achieve its Key Business Objectives (KBOs). Moreover, the cost equation is 
attractive: Development and maintenance of a typical BPM enabled application is 
between one and two thirds of a custom development. 


With continuous process improvement (CPI) as the core discipline of BPM, the 
models that drive work through the firm evolve constantly. Indeed, recent studies 
suggest that firms fine-tune their BPM-based applications at least once a quarter 
(and sometimes as often as 8 times per year). The point is that there is no such 
thing as a “finished” process; it takes multiple iterations to produce highly effective 
solutions - even if business conditions do not change. Every working BPM-based 
process is just a starting point for the future. 


Why is this important? CPI matters because it creates superior performance. But it 
also presents a scale problem for most organizations. Right now, most major firms 
are still experimenting with BPM by focusing on a few, tightly scoped process 
engagements. The core BPM team is growing its capabilities and confidence in 
preparation for more demanding and complex business problems. But with multiple 
processes that could benefit from BPM-style automated support, the issue becomes 
how to support dozens or even hundreds of engagements per year. Current 
application development practices hit the wall under such circumstances - they 
simply cannot cope. 


Without an efficient, iterative BPM delivery capability, firms will fail to achieve the 
performance enhancements they seek. With LOB Managers queuing up for the 
attention of key resources in the BPM team, the introduction of BPM into the wider 
business will falter as a result. While widespread adoption is still possible, it will 
happen more slowly than originally intended. Of course, many firms are currently in 
this situation! Instead of an application backlog, they are building up a BPM project 
backlog. 


Furthermore, without comprehensive support for the process lifecycle, iterations will 
be slower; allowing more agile competitors to evolve their offerings more rapidly. In 
the end, maintaining competitive advantage relies on the ability to adapt more 
quickly than a challenger. 


This paper focuses on how to create an effective methodology and organizational 
capability to meet this challenge. It presents a wide variety of best practice tips and 
pitfalls to avoid, highlighting the experiences of several major enterprises pursuing 
business transformation via BPM. 


Business Drivers for BPM 


In a recent review of BPM case studies, we found that project objectives covered 
several of the headings show in Error! Reference source not found.. Depending 
on the circumstances of the firm, some of these objectives were more important 
than others. Enhancing business performance was the most common goal (lower 
cost and faster cycle time). Becoming “Easy To Do Business With” (ETDBW) and 
more responsive to customer demands was also seen as critical. When looking at the 
customer experience, firms also wanted to integrate their disparate customer 
channels. 
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Figure 1. Firms are looking for a wide range of benefits from BPM 


Others really wanted to focus on integrating their distinct systems and legacy 
applications, re-using their existing IT assets and the embedded fragments of 
process within them. Some wanted to outsource parts of the process or to 
choreograph the distribution of responsibilities amongst suppliers and partners (or 
even to the customer). Most were looking forward to the enhanced agility and lower 
operational risk. For some, better support for regulatory compliance was also critical. 


Regardless of the firm’s objectives, the BPM system had to work with existing 
systems and approaches. In the case of Hasbro, that meant interoperating with the 
firm’s SAP system (see case study below). Like most others, Hasbro set out to 
support the wider business process that surrounded their transactional system. 


Hasbro Case Study 


Hasbro is a $3 billion manufacturer of widely recognized brand name toys. The firm 
now outsources nearly all of its production to a growing list of third party 
manufacturers, most of which are in the Far East. An SAP based ERP system 
captures orders and RFPs from customers in the US, many of which have conditions 
attached (deliver by dates, etc). In the past, orders were broken down and relayed 
to the appropriate suppliers for quotations and responses using faxes, e-mail, and 
phone calls. Replies were chased, collected, and collated before a response was 
provided to the customer. Managing this process was time-consuming, involving the 
manual coordination of a broad array of vendors, manufacturers, and logistics firms. 
Around 200 people were involved in the Hong Kong office alone, and the typical cycle 
time was in excess of 2 weeks to respond to a customer-driven RFP. 


To alleviate this problem, Hasbro built a BPM enabled portal (branded e-Connect) to 
interact with its partners. SAP provided the transaction engine, but Hasbro needed 
BPM to manage the business process that surrounded the transaction. 


Since the introduction of e-Connect, the productivity of those 200 people in Hong 
Kong has gone up by 3 times (it doubled in the first year). So has the business they 
are doing with Wal-Mart, a major customer (also up by 3 times). Just as importantly, 
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e-Connect has given managers at Hasbro complete visibility and traceability on work 
in the system. Average cycle time is now down to less than 24 hours. 


But the benefits did not stop there. With the introduction of the USA PATRIOT Act 
came changes to the level of reporting that was required on all shipments bound for 
the USA - imports had to be tracked and reported at the box level (rather than at 
the container level as it was previously). For a firm like Hasbro, that could have been 
a real problem. Driven by the regulatory change, Hasbro could quickly modify the 
BPM system to update the Purchase Order, Shipping, and Logistics process models. 
They then focused on educating their third party suppliers to work with the new 
customs labeling. 


For Hasbro, this unanticipated benefit gave them real competitive advantage. They 
were able to institute the new processes well before the regulatory change became 
mandatory. So while competitors had their goods tied up on the docks (because they 
had failed to meet the new standards imposed), Hasbro was able to clear customs 
quickly and efficiently, while meeting increased levels of customer demand. Along 
the way, Hasbro has been through five major releases of the e-Connect system in 
the first year of deployment. After four years, the application has been through 
many, many revisions. 


The Fallacy of Requirements Definition 


While the business itself was firmly behind BPM at Hasbro, most organizations regard 
BPM programs as application development initiatives. And, as such, they often suffer 
from a misunderstanding of how different BPM-based process development is from 
traditional IT projects. 


A couple of underlying assumptions underpin the traditional application development 
lifecycle - that business people really do know what they want; and that their 
requirements will not change during development. On the other hand, most business 
people neither understand, nor care, about the technology itself. They are only 
interested in the capabilities it enables. Yet, in the traditional model, accurately 
defining the need for a business system requires users to have a deep appreciation 
for what is possible, and to articulate that vision in painstaking detail. 


After an extensive set of interviews with business analysts, those in the business are 
supposed to sign-off on a document that specifies their precise requirements. The 
design of the overall application architecture happens (Somehow). Systems analysts 
write detailed technical specifications for interpretation by programmers. 
Programmers write code that hopefully meets the needs of the user. Over time, the 
original set of user expectations morphs into a set of computer programs that, 
hopefully, still meet the current business need. 


Of course, such application development projects can take a very long time. And 
because of the time, business people try to pack in all functionality and “nice to 
have” features into the first release. With traditional development approaches, they 
know that years could pass before they get a chance of an upgrade. 


Inevitably, information leakage and miscommunication occurs at every step, leading 
to compromise. Indeed, by the time the development process completes, it is a 
miracle that developers ever deliver effective applications. The application rolled out 
to the business almost fits the originally defined need, but it is often full of 
workarounds and concessions. 


From the perspective of the business users, they usually “see” little until very close 
to the delivery date (that is, apart from documents and specifications). But 
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requirements that look good on paper seldom translate perfectly into a finished 
application. It is only during User Acceptance Testing that many “changes” to the, as 
yet un-deployed, application are identified. 


Once the application has been in use for even a short period, the user expectation 
starts evolving. User requests for new features and enhancements start to appear, 
many of which have fundamental repercussions on the original design. The primary 
reason that technology people want a tightly specified requirements document is to 
discourage change as, from a systems perspective, it is difficult to hit a moving 
target. 


The point is that business requirements always evolve continuously. Whether driven 
externally (by regulation or through competitive pressure), or through a better 
appreciation of what is possible, the system, in the eyes of the business user, is 
always out of date. 


Over the years, technologists have developed a number of strategies and approaches 
to deal with these issues: Detailed specifications, prototyping, agile programming, 
and extreme programming - the problem is that none of these approaches can 
handle the sort of scale problem described earlier. They take too long and rely ona 
waterfall style implementation (where everything arrives all at once at the end of a 
long incubation period). This approach to systems development never did work that 
well. It inevitably failed to deliver what the customer eventually wanted, and often 
led to a damaged user-developer relationship. 


The New BPM Methodology 


Contrast the waterfall style implementation of traditional application development 
initiatives with the spiral methodology employed in BPM programs. Best practice BPM 
implementation methodologies do not assume that business people know exactly 
what they want at the outset (before they have seen anything that works). Instead, 
they initially focus on the 20-40% of functionality that delivers the bulk of the value. 
Thereafter, the models that drive the application are iteratively developed and 
embellished to deliver the fine detail of the needed functionality. BPM-based 
applications are “built to change.” Based on experience of the working application, 
the business users themselves are in a much better position to identify this 
additional functionality. 


Indeed, business users tend to identify functionality that is more appropriate to their 
real needs once they understand the context. This enhanced functionality does not 
stop with the process model. Give the users a way of automatically deriving 
performance metrics from their system, and they immediately want improved, subtly 
different metrics. It is no longer good enough to know the average cycle time. They 
now need to know the cycle time of all shipments to important Customer X, or the 
performance of Team Y in influencing those orders. 


Similarly, the user interface will probably need to evolve. Or, the work distribution 
mechanisms may need to change to reflect a new organizational structure or a 
change in regulation. Indeed, the whole scope of the desired application can change 
quite quickly to reflect an evolving business climate as the firm focuses on a core 
competency while outsourcing other aspects. 


Each one of these different types of changes would normally have major implications 
on a traditional IT application development. On the other hand, a modern BPM Suite 
that provides effective support for the full development lifecycle enables the rapid 
resolution of each issue as it arises. 
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Some of those new requirements emerge from better understanding, while others 
derive from even more pressing competitive dynamics, or changes in regulation as in 
the Hasbro case. In some businesses, it is only with process automation that 
opportunities for further performance improvement emerge. For example, Dell 
Computer used BPM to coordinate their process more effectively with its third party 
shipping agents. But it was only after the initial deployment that the company gained 
sufficient insight into delivery problems to allow it to determine options for 
improvement. 
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Figure 2. Developing BPM enabled applications is a vastly different 
approach to traditional systems development methodologies 


The point is that it is only through use, over time, that the underlying requirements 
for a process support application emerge. No amount of up front business analysis 
could possibly identify all of those needs. They are simply unknowable a priori. 
Nobody really understands the “as-is” process. Equally, no one can truly predict the 
final state. And as the first iteration of the BPM implementation completes, the user 
is already preparing the list of future enhancements. 


Pulte Mortgage Case Study 


At Pulte Mortgage, they already understood their process relatively well. They set out 
to change the model of customer service by becoming more proactive and concluding 
tasks well before customers would reasonably expect completion. But without 
visibility into the metrics of the process, it was difficult to spot opportunities for 
improvement. Through the implementation of an automated case tracking 
application, managers could identify areas where service improvements were 
possible. Indeed, it was only possible to identify requirements once process metrics 
were gathered. 


For example, as a result of the better visibility into the process, managers could 
monitor the number of hours it took to push a case through to the point of offer. As 
the number of cases rose in the queue awaiting approval, managers realized they 
could influence overall performance of the process by lowering the credit- scoring 
threshold (where the system automatically accepts mortgage applications). But as 
they reduced cycle time, the financial risk would rise. This does not mean that 
managers were interested in re-configuring business rules in real time. Rather, as 
part of the manager’s dashboard user interface, the system should now expose slider 
control mechanisms that enable this sort of control. 
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But this is a business judgment, trading off higher risk against more rapid response 
to customers and, hence, more business. As they came to understand the dynamics 
of these decisions, they could then start to embed that enhanced understanding into 
a more dynamic set of business rules that supported the decision (even down to 
suggesting the level of automatic credit scoring approval). 


Vendor Support for Iterative BPM Development 


In regards to supporting that iterative development approach, most BPM vendors 
describe their support as “round-tripping.” They are referring to the spiral 
implementation approach of BPM - from analysis, through development, into 
deployment and then monitoring and optimization. The idea is to engage in short 
cycles of iteration, improving the behavior of the application over time. 


While telling the story of iterative development, the majority of vendors only pay lip 
service to supporting this important aspect of BPM development. Out- of-the-box 
support is usually rudimentary at best, leaving it to the team to develop and support 
a homegrown lifecycle management approach. System administrators and business 
analysts must ensure that the requested functionality is tracked and implemented 
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Figure 3. A simplistic view of the iterative BPM lifecycle 


Features offered are normally limited to support for “version control” of the currently 
running model (ensuring the audit link between process instance data and the 
relevant process model used to drive the work). Others point to their inclusion of a 
bundled simulation environment and robust set of analytics capabilities - as though 
the mere provision of these tools will directly support the lifecycle. Some products 
provide for the parallel running of different versions, allowing the business to pilot a 
new version in a specific area and then compare its performance against the current 
standard. Occasionally there is even support for the configuration management of 
deployed solutions. 


Of course, the BPM lifecycle is itself a collaborative process, involving many 
participants. Best of breed vendors support the entire team as they interact with 
each other. The BPM project manager, the business analyst, process modelers, 
associated IT developers, the deployment team, business managers, subject matter 
experts, end users - all will usually require different tools, but to collaborate 
effectively, they should at least share the same set of underlying models stored in a 
shared repository. Mechanisms for capturing exceptions and supporting their 
management are also important here. Moreover, with a few exceptions, products 
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rarely provide direct support for the engagement of business users in a workshop 
situation. 


Probably, the Lombardi Software product set provides the most effective support for 
this aspect of BPM projects. It explicitly focuses on enabling the effective 
communication between all participants in the BPM development project. It does this 
by ensuring that all parties share the same set of models even where different, role- 
specific user interfaces support the special needs of team members. 


Best Practice BPM Development Methodology 

Just as BPM technology is markedly different from conventional approaches to 
application support, the methodology of BPM development is markedly different from 
traditional software implementation techniques. With the intervals of change getting 
shorter and shorter, firms need to develop an effective methodology to get around 
the business optimization cycle quickly enough. 
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Figure 4. The best practice of BPM involves a number of rapid iterations 


Figure 4 depicts a way of organizing activity and ensuring that the project stays on 
track. The methodology involves many smaller iterations focused on a particular 
topic, each with “playback” sessions where the BPM team, subject matter experts, 
and business managers interactively validate newly developed functionality. This 
approach ensures that no surprises emerge along the way, while delivering the 
flexibility to change as needed. There are iterations in the requirements area 
(Discover and Understand), iterations during the Design phase, iteration at Build and 
Test, etc. Further, managers need to monitor the process and control the way in 
which it operates. Before repeating the cycle again, the Analysis and Optimization 
phase involves several additional iterations as business analysts and managers 
experiment with alternative scenarios. 


Given four or five business optimization cycles per year for a business process, each 
overall cycle must complete within three months. To achieve this, it is necessary to 
time-box the different phases of activity. Otherwise, the temptation is always there 
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to spend longer, which encourages scope creep and increases the risk of project 
failure. 


Process Discovery and Understanding 


Every organization has a different start point and, as a result, different needs. Some 
already have a defined process, others are less well developed. Some want to 
emphasize automation of the process, while others need better tracking, visibility, 
and performance measurement. 


Either way, the first objective is to understand the process. Instead of developing a 
400-page requirements document with every detail tightly specified, focus on tying 
down the core functionality that will deliver the large majority of value. 


There is always a need to capture the “As-Is” process. The underlying requirement is 
to be able to “step outside” of the process and understand it fully. The key 
protagonists need models that enable them to communicate effectively with each 
other. Secondly, these models will form the underlying structure to underpin the 
capture of baseline metrics. It is important to gather reference metrics to ensure that 
the team can later prove the performance improvements. 


To achieve a rich appreciation of the process it is necessary to model the process at 

a high level, from a number of different, complementary perspectives. Assessing the 
business situation using a complementary set of modeling techniques allows people 

to better comprehend the fundamentals of the process. The ideal techniques for this 
phase are: 


e Flow diagrams to look at the order of activities (BPMN); 


e Role Activity Diagrams to focus attention on role interactions and desired 
behavior of the various actors; 


e Object State Transition Network models to focus on how the things moving 
through the process change state; and 


e Capability models to look at the process as sets of re-usable business 
components. (A capability may be composed of other capabilities or 
implemented by a procedure - BPMN style model). 


The emphasis here is on understanding the process - not building models for 
transformation into code or executable process definitions. This then enables both 
the business analyst and the business user to step outside of the business as usual 
view and see the process differently. 


Given suitable access to subject matter experts, a good rule of thumb is that this 
phase of activity should complete within a week or two. While this might sound 
challenging, it is entirely feasible. The trick is to ensure that models are at a suitably 
high level. Always keep in mind the purpose of the modeling and the intended 
audience. Models should be detailed enough to drive understanding and discussion, 
but no more detailed than is necessary to support this aim. 


Best Practice Observations 


v Identify subject matter experts for each area of the business affected by the 
process. Often there are assumptions made by those in related roles that 
prove to be incorrect. 


v Remember that the emphasis is on understanding. Use complementary 
techniques to help the stakeholders to step outside of the box and see things 
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differently. The techniques suggested are not the only ones available. The 
BPM team themselves should undertake an exercise to try different modeling 
approaches and assess for themselves the ones that work best for their 
company and culture. Look at approaches that help challenge the status quo. 


v On complex processes, to ensure that the scope is at the right level, try 
asking “why?” (five times). When clear answers are no longer forthcoming, 
that suggests the appropriate level of scope. For instance, HR Processes are 
inefficient. Why? It takes too long to onboard a new employee. Why? There is 
no coordination between HR-1IS, the Recruiter, and HR Manager on the status 
of a candidate in the process. Why? We have no way to track desired start 
date and when orientation needs to have occurred. Why? | don’t know. This 
sort of analysis will help identify the root cause - ensuring that the scope is 
neither too wide, nor so narrow that the business benefit is minimal. 


v Ensure that the team is able to succinctly and specifically state the practical 
problems associated with the business domain. If that is not possible then it 
suggests more work is necessary to identify the real priorities. 


vy Build a roadmap of the short, medium, and long-term vision for the 
application. Identify chunks of functionality for delivery in successive 
iterations. Re-scope the roadmap on the completion of development cycle. 


Pitfalls 


* Problems can occur in this phase of activity if people decide to set out and 
capture all potential paths through a process, and/or all exceptions, and/or all 
potential activities. This is the root cause of “analysis paralysis.” IT-centric 
analysts wrongly assume that the path to success begins by populating a 
multi-dimensional modeling repository. In the short term, it can kill a BPM 
project as it distracts from the critical requirement of proving the efficacy of 
the BPM approach to the business. 


x Creating the “definitive” Requirements Specification is a waste of time. 
Documents by themselves are flat. Indeed, as stated earlier, the whole notion 
of a definitive requirements specification becomes irrelevant in a BPM project. 


From Design to Deployment 


A comprehensive BPM Suite is necessary to underpin the target process- enabled 
application. The BPM Suite provides a configurable platform that executes procedural 
models, delivering work to the relevant employee or partner (or even customer). It 
ensures traceability of individual cases of work and guarantees compliance. Modern 
BPM Suites include integrated process modeling and business rules environments, 
integration facilities, sophisticated user interface capabilities, and powerful analytics. 


When developing the actual BPM-enabled application itself, the BPM team will find it 
much easier to gain clarity with a deep understanding of the process provided by the 
previous phase. Rather than attempting to define 80-90% of the final functionality, 
start with automating a more modest target of around 20-40% that delivers the vast 
majority of the value. 


However, the process is just one area where work is required in the development 
and implementation phase. Focused effort is essential to ensure effective integration 
with third party applications. Similarly, the user interface will need special attention, 
as will the metrics gathered and the mechanisms provided to managers to control 
the functionality. 
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Rather than trying to address all issues together, focus on just one aspect of the 
development before moving on to the next. Create a separate sub-phase of work for 
each different facet: 


Process Flow - In the initial iteration, the aim is to agree on the core 20-40% 
of functionality that will deliver the bulk of the value. Although a fair amount 
of modeling was undertaken when looking at the “As Is,” this effort is all 
about creating the “To Be” process. Although organizational change may be 
considered a deployment issue, the way in which activities are assigned to the 
groups and roles will also be important. 


Integration - This sub- phase focuses directly on information extraction and 
update from/to external applications. Associated with this sub- phase is design 
of the data for the process. Again, ensuring that the data model is developed 
separately from the “As Is” model ensures that team members design and 
support what is necessary, rather than taking for granted what is there 
already. The deliverable should concentrate on proving to the user community 
that the necessary data can be placed on a default user interface (i.e., do not 
attempt to customize the user interface). 


User Interface - Ensure that the screens deliver the information required by 
the various roles involved in the process. 


Metrics - Explore the management information deemed necessary, how this 
data is gathered, who should have access to it, and how it is presented. Often 
referred to as Key Performance Indicators (KPIs), the BPM Suite should 
capture all the necessary information. It is worth noting that the metrics used 
to track process efficiency and effectiveness may differ significantly from the 
data used to maintain the state of the process. 


Controls - Business managers will want a way of throttling performance of 
the process, allowing them to control process execution. They need 
mechanisms that help them cater with peaks and troughs in demand, or 
influence the way in which business rules apply. 


It is important to separate these portions of the development as it will allow 
specialist resources in the team to focus their efforts. Depending on the situation, 
the order of these sub-phases may change. For example, if extracting data from 
third party applications will present the greatest difficulty, then this sub-phase 
should probably run first. Of course, in many projects, individual sub- phases may 
reiterate based on feedback from those subject matter experts and managers. 


Moreover, each of these sub-phases allows the team to present results back to the 
subject matter experts and management of the business area within a workshop 
situation. Supported by a shared model approach, these interactive playback 
sessions ensure that users can see the implemented functionality requested. 
Moreover, because the outputs are graphical, participants can quickly step through 
the changes made since the last iteration. 


When looking at the capabilities of the BPM Suite, make sure that project team 
participants have direct access to all related events, rules, user interfaces, process 
flows, code, and analysis from the same tool set, in the same context. The product 
should not force application developers and analysts to switch tools or contexts to 
see what is going on in the process. 
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Best Practice Observations 


v Ensure that comprehensive facilities are in place for continuous and ongoing 
collaboration between the business leadership and the BPM team. 


v Make sure that the end users realize that this is not a “once and done” 
system delivery. Ensure that they understand that the team is coming back 
for future iterations on the development so that they do not try to cram every 
detail into the initial release. It may be necessary to produce a functionality 
roadmap with future phases of activity linked to areas of functionality not yet 
implemented. This will help the BPM Team and the end users focus on the 
delivery from this phase of development. 


v Rather than attempting to “transform” the “As Is” model developed in the 
initial phase (Process Discovery and Understanding), build a new set of 
models inside the BPM Suite. This helps to focus on the desired functionality 
for this phase. It removes the temptation to bend the rules in the Discovery 
and Understanding phase (by attempting to put too much detail into models). 
It will also help ensure that the application leverages the features and 
facilities of the BPM Suite. 


vy Locking down the “To Be” process definition in the first iteration can be 
challenging. Even when users know that further iterations are planned they 
will still push for functionality that is less important. Zeroing in on what the 
business really cares about is often difficult. Separate the identification of the 
happy path of the process from the handling of exceptions. In the initial 
iteration of the process flow loop, it may be good enough to capture and 
support the happy path. Subsequent iterations could then capture the major 
exceptions, leaving the more complex exceptions to another release of the 
application. 


v Catalog and weigh exceptions to help identify those that are most important. 
Look at each one in terms of its impact (to the business when it occurs), its 
frequency, and whether it is detectable today. A severe exception may only 
occur twice a year. Or, conversely, an exception that happens frequently may 
have little or no impact to the business. 


v Separate the management of the flow of instances (all cases in the system) 
from the management of a single case. 


vy It is a good idea to ensure that the team carries out a fundamental re- 
assessment of metrics as part of the BPM implementation. Explore how to 
integrate the business relevant data (such as customer, or product 
information) with information on cycle-time, resource utilization, etc. When 
assessing KPIs, make sure that they support the underlying business 
objectives (the firms KBOs). Further, take care to ensure that the measures 
will reinforce the behavior that the initiative is trying to encourage. 


v When presenting finished functionality for any particular facet, ensure that 
the workshop includes a wider group rather than just the managers and 
subject matter experts already involved. This helps to remove errors, identify 
additional functionality for the next iteration, and it encourages broad 
acceptance of the application when released into production. 


~ Consider data and documents implementation details of the process. They are 
normally the mechanisms invented to keep the process coordinated, rather 
than the essence of the process. Look for ways of achieving the real goals of 
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the process without that mechanism of coordination. Removing them will 
probably drive a massive jump in productivity and/or cost reduction. 


When integrating third party applications, take the time to wrap them first in 
Web Services to insulate the process model from any changes in back-end 
systems (and vice versa). 


Remember that both the use and understanding of data also evolves 
iteratively, which can have fundamental implications on the design of the 
process and integration mechanisms. 


Ensure that a subject matter expert is available from each major role affected 
by the system, which is particularly important in the process flow and user 
interface area. Share specialist resources across projects. 


When selecting a BPM Suite, identify a holistic environment that provides 
semantic consistency across different views as participants share the same 
set of models and configuration data. This minimizes any opportunity for 
miscommunication and lowers the cost of development. 


Pitfalls 


* Remember that processes will inevitably change during design and 


development as the details are uncovered. These discoveries can happen at 
any point during the development. Assess each against the agreed scope of 
the project. If the proposed change has a dramatic impact, then identify it for 
a later iteration in development. Too much emphasis on trying to define 
process nirvana is of low value. 


While designing and deploying the process, the temptation is to focus on the 
orchestration of the process. Ensure that equal attention is given to the points 
of process failure. Evaluate each failure for its severity, occurrence, and the 
current controls to detect. 


Monitoring and Control 


The system’s support for business monitoring and control rely on an effective design 
and deployment phase. This section discusses the common types of monitoring and 

control capabilities delivered by BPM Suites. There are several perspectives that are 

important including dashboards, alert and escalation mechanisms, control loops, and 
personnel management. 


Dashboard-style user interfaces deliver appropriate metrics to managers and 
supervisors. The assumption is that managers will intervene where necessary 
to expedite items of work as long as they have suitable visibility on work in 
the system. Of course, the system itself can help facilitate this through the 
provision of mechanisms that enable the manager to inspect the item of work, 
reassign that piece of work, or interact directly with the worker responsible. 
Moreover, the system can prompt individual users directly, bringing to their 
attention items of work that are in danger of exceeding any milestone or 
service level agreement (SLA) established. 


Monitoring and control mechanisms should also enable suitably authorized 
managers to direct the overall operation of the process. When the majority of 
vendors talk about BPM and continuous process improvement, most of them 
are discussing the larger, overall business optimization loop. They have failed 
to grasp the importance of the secondary optimization loop where suitably 
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qualified business managers control the running process directly. Generally, 
this is a design issue. The application should have built-in capabilities that 
provide managers with the controls they need to throttle business 
performance. (See Pulte Mortgage Example on page 10.) 


Best Practice Observations 


v Working with LOB managers, explore how they would react to specific peaks 
and troughs in demand. Work out whether it is possible to provide them with 
mechanisms to influence resource deployment and throughput under these 
circumstances. 


v Ensure that appropriate dashboards are created for every level of the 
organization - from executives (whose dashboards might subsume multiple 
processes) to workers, who will want to “keep score” on their own 
productivity. 


v It is particularly important to provide a focus on the needs of teams and the 
management of the people within them. Concentrate on identifying how much 
work is coming down the pipe, and what the team has to get out the door 
today, tomorrow, this week, or by the end of the month. In turn, this can 
drive a better understanding of what their collective efforts can achieve and 
where they are struggling. 


Pitfalls 


* With every report requested, assess whether the information is actionable. 
Decide on whether the BPM Suite can take action directly. Think of it as the 
difference between reading the news, and MAKING the news. Otherwise, it is 
easy to end up with a lot of “so what” type data points and miss the big 
opportunities. 


Analysis and Optimization 


Analysis and optimization is usually the responsibility of the business analyst or 
process owner. In an ad hoc fashion, these people are looking to identify the 
problems and suggest changes for the next release of the application. They are 
looking at the overall business process, its historical performance and related 
business data with the aim of identifying ways to improve performance. 


Of course, the objectives of the business (the KBOs) should drive performance 
optimization. For most firms, adding more people (resources) to a process to 
improve performance is just not an option. The best BPM products provide 
mechanisms to test alternatives (other than simply adding additional resources at 
bottlenecks). 


Simulation 


In response to this need, most vendors have focused on the provision of simulation 
tools that support the comparison of different what-if scenarios. At its core, 
simulation is a statistical technique that uses probabilities to predict average activity 
durations, queue lengths, resource utilization, etc. 


But usage of simulation should come with a few health warnings. Simulation is most 
effective when used as a way of testing assumptions. For example, if interest rates 
fell, leading to an increase in mortgage applications, what would be the impact on 
the ability of the firm to provide the same level of customer service? At what point 
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would additional resources be required? But simulation models are notoriously 
difficult to construct with each linkage in the model requiring careful statistical 
checking. In the above example, that might mean checking the sensitivity between 
interest rates and the numbers of mortgage applications. Solving this problem entails 
gathering historical data to support this testing. The best BPM simulation tools 
available today extract this data from the running process model to provide the base 
line information, which dramatically changes the cost benefit ratio associated with 
simulation. 


Optimization 


Best in class BPM Suites provide optimization mechanisms that provide automated 
support to help determine the best means of process improvement. This takes 
simulation a step further, addressing some of its inherent difficulties. Rather than 
leaving it to the analyst to determine options for improvement, the system should 
help to identify areas to consider. Moreover, it is often difficult to compare different 
simulated scenarios in ways that are meaningful to the business; for example: 


e Business managers are usually most interested in assessing the effectiveness 
of a particular product or service. It is not good enough to know the average 
cycle time of all loans; they want to know the cycle time of the J umbo loan 
(since they know that has the best margin). Or, they want to assess a 
particular line or service by sales channel. 


e Alternatively, they may look to analyze performance over time, comparing 
some slice of the past with current results, or looking into the future. For 
example, rather than looking at the average over the last six months, a 
manager might want compare the Holiday sales season with the Summer 
sales season. Or, look at the amount of business in production today and 
compare that with the business situation three months ago, or the same 
period last year. 


Best Practice Observations 


v Inthe BPMS environment, all process-related information should be 
accessible via the graphical representation. Ensure that the product allows 
direct access to all events, rules, user interface screens, flows, and analysis - 
from the same tool, in the same context. Support for best practice involves 
one holistic environment; this gets everyone on the same page when 
communicating, thereby avoiding the telephone game. 


v Along with analyzing activity durations and resource utilizations, it is also a 
good idea to look at paths - identifying the percentage of work that follows 
the happy path of the process, versus the number spent on exceptions, or 
complex approvals. 


vy The BPM Suite should provide mechanisms to slice and dice the information 
on performance, linking historical process performance data with the Line of 
Business (LOB) data of the application domain. The BPM Suite itself should 
include optimization features that spot trends and suggest potential 
improvement options, identifying changes to business rules and process logic. 
Look for the ability to view this optimization data in the same diagram as the 
process modeling environment. 
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Pitfalls 


* Simulation is not an end in itself. It is one of many diagnostic tools. Do not 
rely on any one piece of information or one tool as being 100% accurate in its 
conclusion. Processes are multi-dimensional and so is the “truth.” Use a 
variety of analysis techniques to isolate the most critical factors that affect 
the ability of the process in support of its Key Process Indicators (KPIs) and, 
as a result, underpin the Key Business Objectives (KBOs) of the firm. 


* Avoid simulation models that are deterministic in nature. Such models are 
usually designed to prove to management a positive return on some proposed 
change. As a result, they often reflect the agenda of the modeler rather than 
the reality. They usually bury assumptions rather than surface them. 


Growing the Team’s BPM Capabilities 


So how does an organization go about improving its ongoing BPM delivery 
capabilities? Clearly, experience will grow over time. But responding to the situation 
outlined in the introduction - where the organization needs to support dozens of BPM 
engagements per year - has its challenges. Firms should develop a proactive 
strategy to manage and grow the knowledge of the BPM team, capturing insights and 
developing effective engagement methods. 


The most common response to this challenge is to develop a BPM Center of 
Excellence (CoE) or Process Management Office. The idea is that a group of 
committed individuals will focus on the processes of the firm as they drive bottom- 
line profitability and performance. The team can support a number of BPM projects 
across the business, keeping momentum going across a broad front. They are 
usually responsible for developing common principles, language, frameworks, and 
methodologies for process development and process architecture management. 


However, in the early stages, the CoE can present an unnecessary overhead as it 
typically has a much wider scope than is necessary for a pilot project. The CoE 
concept comes into its own as the BPM program starts to address the needs of the 
wider organization. With more and more projects, the need increases for a 
coordinated and integrated approach. The CoE provides a central repository for 
knowledge and best practices development around BPM projects. 


Best Practice Observations 


~ Benchmarking - As a first step, it is a good idea to conduct benchmarking 
exercises with other organizations. Rather than learning only from those of a 
similar size and culture, the group should also compare approaches with firms 
that have a fundamentally different view of how to organize BPM initiatives. 


~ Grow the process acumen of the team by assessing different approaches - 
Take time to weigh different approaches (especially for process and business 
modeling). Rather than looking for a single approach for all situations, assess 
which techniques best support different types of scenarios. By necessity, this 
type of activity involves bringing in outside experts to educate and facilitate 
discussions 


v Adopt an iterative development methodology, supported by appropriate 
technology. The old linear application development methodologies just will not 
scale to handle the number of engagements. Neither will they provide the 
agility needed for survival in a rapidly evolving business environment. 
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v At first, do not bite off more than you can chew. Given the fundamentally 
different approach to development and implementation, it is vitally important 
to prove the effectiveness and validity of the approach. So look for a short, 
tightly scoped project that allows the team to build skills and experience. The 
project should have relatively low complexity and a clear business benefit. 


vy Share the high-level vision with the business users along the way. Help them 
to understand the iterative approach, with multiple releases in quick 
succession. Otherwise, they will assume that the time between releases is 
infinity and will push for too much functionality in the first release, making it 
unnecessarily complex. Share the iterative builds with business users to make 
them more comfortable with the overall approach. 


v The relationship between Process Owners, Business Owners, the Center of 
Excellence, and an individual BPM project team requires careful consideration. 
Address governance issues comprehensively and early. Identify process 
owners to sustain/support applications once in production. Agree on change 
procedures, expectations on resource availability, etc. 


v “Before Action Review” and “After Action Review” - This is the most important 
mechanism to grow the BPM capabilities of the firm over time. For each 
project, focus on short cycles of plan, prepare, execute, and review. For each 
project, phase, and sub-phase, plan the engagement with the user 
community. Set objectives for each deliverable and brief the team to ensure 
that they fully understand the rationale. Conduct formal BARs and AARs for 
the entire project, for each phase and sub-phase. By necessity, the BAR-AAR 
cycle for sub- phases will be relatively brief affairs. Encourage all team 
members to take notes and participate in these meetings.’ 


Conclusion 


For firms to make the most of BPM initiatives, they must first realize that they should 
adopt a different way of working. The methodology of BPM application development 
is vastly different from that found in even the most agile programming environment. 
Rather than the traditional waterfall style implementation - where application 
functionality appears in large monolithic blocks - Titeration and adaptation are 
prevalent in every phase of the development lifecycle. Instead of a timeline 
measured in years and months, application updates roll out in a few weeks or 
months. 


From a BPM technology perspective, it is important to identify a product that 
supports the entire BPM lifecycle, facilitating both the interaction of the various 
individuals involved as well as identifying process trends and optimization options. 
Alongside the technology component, the vendor should provide a robust 
development and implementation methodology with direct support provided by the 
platform itself. The technology and methodology components are interdependent. 


' For more on BAR-AAR see “Learning in the Thick of It” by Marilyn Darling, Charles Parry, and 
Joseph Moore in the J uly-August 2005 issue of Harvard Business Review. 
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